1. Technical Field
The present invention relates to an architecture for graphical representation. More particularly, the present invention relates to management and analysis of authentication tokens in Java. Still more particularly, the present invention relates to an architecture for a graphical representation of the management and analysis of authentication tokens in Java.
2. Description of Related Art
With the proliferation of computer business and the ever expanding internets and Internets, vendors are scrambling to meet the security needs of their customers. Vendors are presented with security issues in a broad range of applications. Electronic commerce in business-to-business and home-to-business applications implies a selectable range of security solutions which are difficult to incorporate in a single application. Content distribution of software, reference information, educational material, or entertainment content require new algorithms and protocols to keep ahead of attacks from hackers. Metering of content, service, or both, and the requirement for secure storage of state and value becomes more important with the increasing number of protocols and cryptographic applications. Securing business or personal activity for private e-mail, home banking, and monetary transactions require a wide range of security solutions where the value of the data, and thus the threat, may be quite varied.
The CDSA (Common Data Security Architecture) was conceived by the Intel Corporation 2200 Mission College Blvd. Santa Clara, Calif. 95052 in response to the above mentioned concerns. CDSA describes a pluggable model for cryptographic and certificate services. This architecture is most commonly implemented as a set of DLLs (Dynamically Linked Libraries). A framework DLL is present that controls all access to “plugin” DLLs that actually perform CDSA services (e.g., encryption, signature, digital certificate parsing, and digital certificate validation). The API (Application Programming Interface) to the framework DLL is a published standard.
Normally, all applications built to the CDSA standard will execute successfully on a given CDSA implementation. This means that all CDSA applications have access to all cryptographic services plugged in to the framework DLL.
This framework presents problems when exporting applications which support CDSA implementations. The problems occur when exporting a CDSA implementation to jurisdictions where other CDSA applications are not legally allowed to use the specific cryptographic services of the CDSA implementation, thus it may be impossible to use the CDSA implementation in a vendor's CDSA application product. One problem is that CDSA is implemented in dynamically linked cryptographic libraries, which leaves the encryption APIs open for illegal use. Another problem is that the API to the framework DDL is a published standard.
Currently vendors give up the advantages of the CDSA in order to solve these problems. They statically link cryptographic libraries to their applications. Static libraries are not flexible (e.g., untouched, the application cannot take advantage of new plugin implementations automatically) and which waste space (each application carries along a copy of the static library code and multiple copies are loaded into memory when multiple applications run).
Also, Java Authentication and Authorization Service (JAAS) has recently been developed. JAAS is a new and emerging security model that uses login modules to provide authentication and a modified Java 2 policy to provide authorization. The login modules may perform one of many types of user identity verification such as accessing native system information, certificate databases, or smart cards. After authentication, JAAS creates principals based upon the user's defining qualities such as username, system groups, serial number, domain, and the like. The principals can then be used to define granted permissions, which represent a finer granularity of the Java 2 policy file model.
In a typical present scenario, users execute a Java application or applet under the layer of a controlling security model. When controlled by a security model, Java applications are subject to authentication as well as authorization processes that ultimately decide the success or failure of the applications. All models provide authorization based upon prescribed permissions usually contained within user created policy files. In addition, some security models utilize authentication to verify who is executing the application. For example, a database of certificates, passwords, or Kerberos tickets may be used to authenticate the user. Once authorization has been verified, the application may proceed to execute as long as it does not violate the security policy. As a result, success or failure of the application may be determined by both authentication and authorization rules.
Therefore, it would be advantageous to have a user interface that provides a comprehensive graphical representation of the authentication process. Further, it would be advantageous to offer the ability to dynamically depict active principals, as well as runtime failures in Java applications that are due to inadequate policy failures or login modules.